> >On Sep 19, 4:33pm, Sten Gunterberg wrote: > >> (Hmm. Howcum my mailer missed the attrib? Gotta fix that or the header somehow got bolluxed - anyway)... Casper apparantly sez: > That's an error in the bug report. Since 4.1.4 was out long before > the scare, the bug does exist in 4.1.4. Not surprising - and it probably is in about everything on any platform that uses syslog(3) and lacks a bounds-checking sprintf()... I wonder about the logger(1) command - is there any bounds checking in it, or can one stomp all over the stack and cause syslogd to core... stopping any future logging? I wonder if there is any element of protection by having the sendmail daemon running only on machines that have no user accounts (all passwd entries have '*' for the passwd field, except for systems staff, of course)? All other machines having sendmail NOT running as a daemon, and the SUID bit turned off (because it doesn't do local delivery)... > The simple facts are: > - all sendmails are vulnerable > - it's a syslog() problem, not really a sendmail problem. I suspect that when the patch is out, it will be a libc patch, or at least a new module to replace one in libc, not a patch to sendmail, syslogd, or other utils... Thats how I am thinking of fixing it, if the patch is not forthcoming soon... replacing the syslog.o module in libc.a and libc.so.??? (so statically linked stuff subsequently built won't be vulnerable, too)? I take it that Suns syslog() function doesn't do anything undocumented and wierd... I am understanding this bug correctly, right? > While syslog()'s output can be limited in length by carefully specifying > the format, some systems don't support more than 128 bytes of messages. > [ ... ] > - bug for SunOS 4 (as listed above) > - bug for Solaris libc (as listed above) > - bug for Solaris 2.x /usr/4lib/libc.so.?.* > Casper -- #include <std.disclaimer> Pat Myrto (pat@Wolfe.NET) Seattle WA A sysadmin's life is a sorry one. The only advantage he has over Emergency Room doctors is that malpractice suits are rare. On the other hand, ER doctors never have to deal with patients installing new versions of their own innards! -Michael O'Brien